home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0128 / 394.txt < prev    next >
Text File  |  1997-04-16  |  25KB  |  623 lines
  1. Info-Atari16 Digest         Tue, 16 Jul 91       Volume 91 : Issue 394
  2.  
  3. Today's Topics:
  4.                          3D Animation/Lexicor
  5.                  An idea for DC Software? (wish list)
  6.                         APPLE + IBM Agreement
  7.                            Atari's monitors
  8.                       atari amiga inc. (2 msgs)
  9.                        comp.sys.ibm.pc (2 msgs)
  10.                  Corrupted GPLOT.ARC file .. (2 msgs)
  11.                     Diamond Back II latest version
  12.                         gcc / g++ for the ST?
  13.                                 NROFF
  14.                       Portfolio in Terminator 2?
  15.                        Problems with FATSPEED.
  16.                        Ramdisk assisted booting
  17.                          Reset-Proof Ramdisk
  18.                       Supra vs. ICD controllers
  19.             Wanted - info on Mega ST 8/16 MHz accelerators
  20.             weather fax (wefax) satellite images on atari
  21.  
  22. Welcome to the Info-Atari16 Digest.  The configuration for the automatic
  23. cross-posting to/from Usenet is getting closer, but still getting thrashed
  24. out.  Please send notifications about broken digests or bogus messages
  25. to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU.
  26.  
  27. Please send requests for un/subscription and other administrivia to
  28. Info-Atari16-Request, *NOT* Info-Atari16.  Requests that go to the list
  29. instead of the moderators are likely to be lost or ignored.
  30.  
  31. If you want to unsubscribe, and you're receiving the digest indirectly
  32. from someplace (usually a BITNET host) that redistributes it, please
  33. contact the redistributor, not us.
  34. ----------------------------------------------------------------------
  35.  
  36. Date: 16 Jul 91 04:31:44 GMT
  37. From:
  38.  noao!ncar!elroy.jpl.nasa.gov!usc!rpi!zaphod.mps.ohio-state.edu!magnus.acs.ohio-
  39.  state.edu!bmakuch@arizona.edu
  40. Subject: 3D Animation/Lexicor
  41. To: Info-Atari16@naucse.cse.nau.edu
  42.  
  43.  Has anybody heard of a company called Lexicor Software? They
  44.  are producing a 3D package called the Phase-4 Animation system
  45.  for the ST as well as a 24 bit graphics card.  Any info, like
  46.  their address or articles in magazines about their product,
  47.  would be much appreciated.
  48.  
  49. ------------------------------
  50.  
  51. Date: 16 Jul 91 15:55:28 GMT
  52. From:
  53.  noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!cs.umn.edu!thelake!steve@a
  54.  rizona.edu (Steve Yelvington)
  55. Subject: An idea for DC Software? (wish list)
  56. To: Info-Atari16@naucse.cse.nau.edu
  57.  
  58. [In article <2436@uqcspe.cs.uq.oz.au>,
  59.      warwick@cs.uq.oz.au (Warwick Allison) writes ... ]
  60.  
  61.  > mforget@ersys.edmonton.ab.ca (Michel Forget) writes:
  62.  >
  63.  >>timothyg@ncsa.uiuc.edu (Timothy Gallivan) writes:
  64.  >>>
  65.  >>> How about a spooler that tests
  66.  >>> the size of a spooled file, mallocs enough memory, then shrinks itself
  67.  >>> when the file has been printed.
  68.  >
  69.  >>Sometimes I want to print something that is only two or
  70.  >>three kilobytes, and it seems like such a waste to keep a thirty-two
  71.  >>kilobyte buffer.
  72.  >
  73.  > I'm in the opposite position:  I'd like a spooler that spooled to disk,
  74.  > and read back in chunks (eg. 4K) for printing.  That would make printing
  75.  > from PageStream much more pleasant on my 9-pin.  I believe the lpr stuff
  76.  > with MiNT did this.
  77.  >
  78.  > What are the pitfalls of having a TSR access the disk?  If I knew them,
  79.  > I would gladly write such a spooler.
  80.  
  81. I think that Malloc() and file handling share the same primary pitfall,
  82. which is that under GEMDOS, only the current process may ``own'' either
  83. dynamically allocated memory or file handles. If the current program
  84. terminates, the memory and file handles will be invalid.
  85.  
  86. If this is the case (and I'm not a developer, but merely repeating what
  87. I've been told on the net), then the method that Timothy suggested
  88. couldn't work -- at least not with Malloc(). There might be a workaround
  89. using high memory, or there might not.
  90.  
  91. The way around the file handle problem is fairly easy --  open a file,
  92. read a chunk, and close it. Keep track of where you are. Then reopen, seek
  93. the old position, read some more and close. Be sure that you never allow a
  94. task switch while a file is open. (If you're a DA, beware of AES
  95. functions.) That way you could keep replenishing a static buffer without
  96. running a risk of losing a file handle.
  97.  
  98.  ----
  99.  Steve Yelvington <steve@thelake.mn.org>
  100.  Marine on St. Croix, Minnesota
  101.  
  102. ------------------------------
  103.  
  104. Date: 15 Jul 91 15:29:28 GMT
  105. From: uupsi!mpoint!ritz@nyu.arpa (Chris Mauritz)
  106. Subject: APPLE + IBM Agreement
  107. To: Info-Atari16@naucse.cse.nau.edu
  108.  
  109. In article <1991Jul11.143617.11866@crash.cts.com> chuckie@pro-odyssey.cts.com
  110.  (Chuck Schul) writes:
  111. >In-Reply-To: message from shawl@kuhub.cc.ukans.edu
  112. >
  113. >it is the best thing to happen ever!ibm running apple o/s ,apple using
  114. >advanced ibm technology!next year should be interesting now suddenly
  115. >nothing else compares!the end of windows is near!!!and now we can have the
  116. >power to be our best!(maybe specture will even run system 7 one day!!!
  117.  
  118. I think the technology sharing aspect of this deal was secondary.  IBM
  119. is probably doing this to avoid wasting time/money on litigation with
  120. Apple over their "Maclike" GUI in OS/2.
  121.  
  122. Cheers,
  123.  
  124. Chris
  125. --
  126. ------------------------------------+---------------------------------------
  127. Chris Mauritz                       |People are strange
  128. ritz@msb.com                        |when you're a stranger.
  129. Copyright (C) 1991                  |The Doors-
  130.  
  131. ------------------------------
  132.  
  133. Date: 16 Jul 91 15:58:30 GMT
  134. From:
  135.  noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!cs.umn.edu!thelake!steve@a
  136.  rizona.edu (Steve Yelvington)
  137. Subject: Atari's monitors
  138. To: Info-Atari16@naucse.cse.nau.edu
  139.  
  140. [In article <1991Jul16.033229.11046@world.std.com>,
  141.      azog@world.std.com (azog-thoth) writes ... ]
  142.  
  143.  > Anyways. What I want to know is why Atari didnt make _one_ monitor for
  144.  > _all_ resolutions.
  145.  
  146. In 1985, when the ST came to market, a monitor capable of displaying all
  147. three resolutions would have cost several times as much as the computer.
  148. You can buy such monitors now, but they compromise the quality somewhat.
  149.  
  150.  ----
  151.  Steve Yelvington <steve@thelake.mn.org>
  152.  Marine on St. Croix, Minnesota
  153.  
  154. ------------------------------
  155.  
  156. Date: 16 Jul 91 03:18:23 GMT
  157. From: noao!asuvax!ncar!elroy.jpl.nasa.gov!usc!apple!netcomsv!seitz@arizona.edu
  158.  (Matthew Seitz)
  159. Subject: atari amiga inc.
  160. To: Info-Atari16@naucse.cse.nau.edu
  161.  
  162. In article <A0b8ia7i@mwowm.mantis.co.uk> mathew@mantis.co.uk writes:
  163. >
  164. >CDTV is very much a case of "What can we throw together quickly in order to
  165. >grab some market share before everyone else?"  And that's the sort of
  166. >attitude which has killed countless products in the past, the one real
  167. >counterexample being the IBM PC which has staggered on regardless of its
  168. >fundamental design flaws and incompatabilities with the standards of the
  169. >time.
  170. >
  171. >But Commodore aren't IBM.  They can't hope to push CDTV into being a de facto
  172. >standard when they're faced with companies like Sony and Philips.
  173. >
  174. >
  175. >mathew
  176. >--
  177. ><< baby  mother  hospital  scissors  creature  judgement  butcher  engineer >>
  178.  
  179. I work for a company that is heavily involved in CD-ROM publishing equipment.
  180. Frankly, we've seen very little happening in either CD-I or CDTV.  Many
  181. companies are just getting into CD-ROM, and those that are already in CD-ROM
  182. seem happy to stick with ordinary CD-ROM.
  183.  
  184. We've been interested in looking at supporting CDTV.  Unfortunately, Commodre
  185. CDTV division seems to have a similar attitude to Atari's developer support.
  186. We can either purchase (through barter) a full CDTV development system complete
  187. with Amiga, or we get nothing.  All we want is a specification at this point,
  188. and we can't get it.
  189.  
  190. I crossposting this article to alt.cd-rom and directing Follow-Ups there, since
  191. my posting has very little to do with Atari (or any particular computer).
  192.  
  193.  
  194.  
  195. --
  196.                                         Matthew Seitz
  197.                                         seitz@netcom.com
  198.  
  199. ------------------------------
  200.  
  201. Date: 15 Jul 91 15:26:30 GMT
  202. From: uupsi!mpoint!ritz@nyu.arpa (Chris Mauritz)
  203. Subject: atari amiga inc.
  204. To: Info-Atari16@naucse.cse.nau.edu
  205.  
  206. In article <1991Jul11.111620.4736@crash.cts.com> chuckie@pro-odyssey.cts.com
  207.  (Chuck Schul) writes:
  208. >apple and ibm,soon atari and commodore will see eye to eye,cdtv a step
  209. >forward what a concept!@
  210.  
  211. What would Commodore gain from this?  In all seriousness, I think getting
  212. involved with Atari in the same manner as IBM-Apple wouldn't gain them
  213. anything except increased debt.  Commodore seems to be getting on its
  214. feet, both financially and technology-wise, all by itself.  In short,
  215. I think the vast majority of the benefits for such a union would go
  216. in one direction Commodore >>> Atari  so Commodore would have no incentive
  217. to seek such a union.
  218.  
  219. Cheers,
  220.  
  221. Chris
  222. --
  223. ------------------------------------+---------------------------------------
  224. Chris Mauritz                       |People are strange
  225. ritz@msb.com                        |when you're a stranger.
  226. Copyright (C) 1991                  |The Doors-
  227.  
  228. ------------------------------
  229.  
  230. Date: 16 Jul 91 12:32:48 GMT
  231. From: mcsun!unido!pcsbst!dude!me@uunet.uu.net (Michael Elbel)
  232. Subject: comp.sys.ibm.pc
  233. To: Info-Atari16@naucse.cse.nau.edu
  234.  
  235. In <1991Jul15.144652.9009@convex.com> rosenkra@convex.com (William Rosenkranz)
  236.  writes:
  237.  
  238. >pbm is too big to send. get it on your own from a.a. it is not a single
  239. >program, more like a library of general purpose utilities (lots of them)
  240. >to manipulate images of various formats. as far as i know there is no
  241. >support for TIFF, however, which is somewhat suprising.
  242.  
  243. Isn't there, then someone must have left it out of the atari port.
  244. I definitely have a 'tifftopgm' in my sources of pbmplus.
  245.  
  246. Michael
  247. --
  248. Michael Elbel                   |  Wollen haetten wir schon moegen
  249. PCS GmbH, Muenchen, Germany     |  aber duerfen haben wir uns nicht getraut.
  250.    me@dude.pcs.com              |  - Karl Valentin
  251.  
  252. ------------------------------
  253.  
  254. Date: 16 Jul 91 07:52:45 GMT
  255. From: mcsun!ukc!edcastle!robin@uunet.uu.net (R C Smith)
  256. Subject: comp.sys.ibm.pc
  257. To: Info-Atari16@naucse.cse.nau.edu
  258.  
  259. In article <50966@olivea.atc.olivetti.com> messina@king.ico.olivetti.com (Gianni
  260.  Messina) writes:
  261. >I need to convert an Atari ST graphics file (IMG or PI3 format) to a
  262. >PC IBM Windows 3 (TIF, BMP or GIF format).
  263. >
  264. >Is there someone that have a PD available program for ATARI ST or
  265. >IBM PC that can send me?
  266.  
  267. The portable bitmap plus (PBMplus) can convert IMG and PI3 to TIF or
  268. GIF, I think this program has been ported to both ST and IBM PC..
  269.  
  270.  
  271. Cheers
  272.  
  273.  
  274.  
  275.  
  276. Robin
  277.  
  278. ------------------------------
  279.  
  280. Date: 14 Jul 91 15:01:09 GMT
  281. From: mcsun!ukc!warwick!nott-cs!lut.ac.uk!elmar@uunet.uu.net (Mohammad A. Rahin)
  282. Subject: Corrupted GPLOT.ARC file ..
  283. To: Info-Atari16@naucse.cse.nau.edu
  284.  
  285. It seems that the file gplot.arc recently sent to atari.archive is corrupted.
  286. I've tried to unarchive this under UNIX as well as under ST. In both cases
  287. the attempt failed with CRC error check. My file transfer is quite ok and I've
  288. been doing this for some time. Would the original sender please send the file
  289. once again to atari.archive.
  290.  
  291. Thanks in advance.
  292.  
  293. - Rahin
  294.  
  295. ------------------------------
  296.  
  297. Date: 16 Jul 91 12:54:07 GMT
  298. From: mcsun!unido!sbsvax!sbuvax!univwa@uunet.uu.net (Bernhard Stumpf)
  299. Subject: Corrupted GPLOT.ARC file ..
  300. To: Info-Atari16@naucse.cse.nau.edu
  301.  
  302. In article <1991Jul14.150109.11886@lut.ac.uk>, M.A.Rahin@lut.ac.uk (Mohammad A.
  303.  Rahin) writes:
  304. >
  305. > It seems that the file gplot.arc recently sent to atari.archive is corrupted.
  306. > I've tried to unarchive this under UNIX as well as under ST. In both cases
  307. > the attempt failed with CRC error check. My file transfer is quite ok and I've
  308. > been doing this for some time. Would the original sender please send the file
  309. > once again to atari.archive.
  310. >
  311. > Thanks in advance.
  312. >
  313. > - Rahin
  314.  
  315. Rahin is right, I was also disappointed making the same experience.
  316.  
  317.   - Bernhard
  318.  
  319.  
  320. -----------------------------------------------------------------------------
  321.     Dipl. Ing. Bernhard Stumpf            phone : ++49-681-302-4143
  322.     University of the Saarland            e-mail: bestu@sbuvax.rz.uni-sb.de
  323.     Geb.5 - Zi.218
  324.     Im Stadtwald                                        |||
  325.     D-6600 Saarbruecken                                 |||
  326.     Germany                                            / | \
  327. -----------------------------------------------------------------------------
  328.  
  329. ------------------------------
  330.  
  331. Date: 16 Jul 91 03:37:05 GMT
  332. From:
  333.  noao!asuvax!ncar!elroy.jpl.nasa.gov!usc!samsung!rex!uflorida!mailer.cc.fsu.edu!
  334.  nu!boyd@arizona.edu (Mickey Boyd)
  335. Subject: Diamond Back II latest version
  336. To: Info-Atari16@naucse.cse.nau.edu
  337.  
  338. Is 2.01 the latest version of Diamond Back II?
  339.  
  340. --
  341.     ---------------------------------+-------------------------------------
  342.              Mickey R. Boyd          |  "Kirk to Enterprise.  All clear
  343.           FSU Computer Science       |      down here.  Beam down
  344.         Technical Support Group      |      yeoman Rand and a six-pack . ."
  345.        email:  boyd@nu.cs.fsu.edu    |
  346.     ---------------------------------+-------------------------------------
  347.  
  348. ------------------------------
  349.  
  350. Date: 16 Jul 91 10:29:47 GMT
  351. From: mcsun!unido!ira.uka.de!ira.uka.de@uunet.uu.net
  352. Subject: gcc / g++ for the ST?
  353. To: Info-Atari16@naucse.cse.nau.edu
  354.  
  355. For a friend of mine I'm looking for the GNU C or GNU C++ compiler.
  356. Does anyone know if it's ported and how to get it INCLUDING DOCUMENTATION?
  357.  
  358. please MAIL me, because I'm not reading this group!
  359.  
  360. thanx, angelo
  361.  
  362. ------------------------------
  363.  
  364. Date: 16 Jul 91 07:35:20 GMT
  365. From:
  366.  noao!ncar!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!utgpu!watserv1!watmath!ljdic
  367.  key@arizona.edu (L. J. Dickey)
  368. Subject: NROFF
  369. To: Info-Atari16@naucse.cse.nau.edu
  370.  
  371. In article <1991Jul14.224236.11159@netcom.COM> seitz@netcom.COM
  372.         (Matthew Seitz) writes:
  373. >Is there a utility available to print out nroff files?
  374.  
  375.  
  376. The archive: atari.archive.umich.edu has nroff.
  377. It is available by "ftp" or by mail.
  378.  
  379. --
  380. Prof L.J. Dickey, Faculty of Mathematics, U of Waterloo, Canada N2L 3G1
  381. internet:       ljdickey@watmath.UWaterloo.ca   BITNET/EARN:    ljdickey@watdcs
  382. obsolescent?:   ljdickey@watmath.waterloo.edu
  383. UUCP:           ljdickey@watmath.UUCP   ..!uunet!watmath!ljdickey
  384.  
  385. ------------------------------
  386.  
  387. Date: 16 Jul 91 04:32:09 GMT
  388. From:
  389.  noao!asuvax!ncar!elroy.jpl.nasa.gov!usc!samsung!noose.ecn.purdue.edu!cb.ecn.pur
  390.  due.edu!whitehe@arizona.edu (Drew D Whitehead)
  391. Subject: Portfolio in Terminator 2?
  392. To: Info-Atari16@naucse.cse.nau.edu
  393.  
  394. I heard that at least the upper mgmt had no knowledge of the Portfolio in
  395. Terminator 2.
  396.  
  397. Astalavista...
  398.  
  399. Drew
  400.  
  401. ------------------------------
  402.  
  403. Date: 16 Jul 91 14:58:13 GMT
  404. From: richsun!chuck@uunet.uu.net (Chuck Menard)
  405. Subject: Problems with FATSPEED.
  406. To: Info-Atari16@naucse.cse.nau.edu
  407.  
  408. In article <GJH.91Jul10103404@ghiggins.hpl.hp.com> gjh@hplb.hpl.hp.com (Graham
  409.  Higgins) writes:
  410. >
  411. >I have been asked by M.Bouron@uk.cray.com (Marc Bouron) to post this for him.
  412. >
  413. >------------------------------------------------------------------------------
  414. >I am having a few problems now that I've downloaded FATSPEED.  I cannot write
  415. >to any HD partitions ("disk full"!!) and `show information' eventually crashes
  416. >with four bombs (illegal instruction).  Delete and rename work fine :-|
  417. >
  418. >I have NeoDesk 2.06 running over TOS 1.0 -- does anyone know any problem with
  419. >such a configuration?  I have stripped out my AUTO folder, so I am just running
  420. >ICDBOOT.SYS, FATSPEED.PRG, and STARTGEM.PRG -- this had no effect...
  421. >
  422.  
  423. I was wondering if you or someone else had posted this question already. So,
  424.  since
  425. there was no answer yet, I'll try:  I have NeoDesk 3.? with TOS 1.0 and many
  426. other programs in my AUTO folder along with half a dozen accessories starting up
  427. at boot time.  Initially, I couldn't get FATSPEED running (I think that was with
  428. my old version of NeoDesk 2.?).  Just recently I read a post, from this net I
  429. believe, that mentioned to put FATSPEED first, even before PINHEAD.  Well, now
  430. everything is working fine and FATSPEED helps out a lot, especially since my
  431. hard drive (Supra 30M) is near full.  Maybe your HD has problems(?).  Possibly,
  432. someone else can shed some light on this problem?
  433.  
  434. CUL,
  435. Chuck
  436.  
  437. ------------------------------
  438.  
  439. Date: 16 Jul 91 04:28:30 GMT
  440. From:
  441.  noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!rpi!clarkson!sun
  442.  .soe.clarkson.edu!AAron@arizona.edu
  443. Subject: Ramdisk assisted booting
  444. To: Info-Atari16@naucse.cse.nau.edu
  445.  
  446. I have a 4meg STe, and no harddrive.  I didn't realize that others were
  447. dealing with problems like setting up their ramdisks upon booting also...
  448.  
  449. My solution: a BOOT DISK to create and fill the ramdisk and
  450.              a REBOOT DISK to do minimum to restore ramdisk and control.
  451.  
  452. GEMINI booting with a 2.8 Meg ramdisk
  453. -------------------------------------
  454. BOOT DISK -- Used on cold boot to get into the GEMINI environment and
  455.              set up the RAMDISK file system.
  456.  
  457.              Contains AUTO folder with: Resetable ramdisk program,
  458.                                         GEMINI stuff,
  459.                                         Screen saver,
  460.                                         GDOS equiv. (looks for fonts on A:),
  461.                                         etc...
  462.              Contains ACCESSORIES
  463.              Contains GEMINI:           Program, Fonts, ...
  464.                                         (GEMINI.APP is set from the
  465.                                         desktop as an AUTO GEM program)
  466.              Contains MUPFEL.MUP:       Sets environment, runs A:LOCAL.MUP
  467.                                         (NOTE: Calls LOCAL.MUP on FLOPPY)
  468.              Contains A:LOCAL.MUP:      Creates Ramdisk file system,
  469.                                         Copies files to ramdisk
  470.                                         (Including all of GEMINI),
  471.                                         Uncompresses files to ramdisk
  472.                                         (To save LOTS of space on floppy)
  473.  
  474. REBOOT DISK -- Warm boots quickly since ramdisk is already set up
  475.                with GEMINI and any other applications.  Still has ACCs
  476.                and \AUTO.  Used if STe ever crashes.
  477.  
  478.              Contains SAME FILES AS BOOT DISK with the following diffs:
  479.  
  480.              GDOS looks for fonts on RESET PROOF RAMDISK,
  481.              GEMINI files are not on floppy,
  482.              GEMINI.APP in the RAMDISK is set from the desktop as AUTO GEM,
  483.              A:LOCAL.MUP contains no file system creation commands
  484.  
  485. MiNT/MGR booting with a 2 Meg ramdisk
  486. -------------------------------------
  487. BOOT DISK and REBOOT DISK follow the same concept of GEMINI disks.
  488. My MiNT boot disk creates a Ramdisk file system, sets up environment,
  489. unarchives \BIN (which contains BASH among other things) and \MGR,
  490. then runs mgr...
  491.  
  492.  
  493. -------------------------------------
  494. Leaving me in a system where I can pop the floppy and be functional without it.
  495. (I end up with GEMINI/MGR, BIN stuff, EMACS and UNITERM/MGRTERM in ram)
  496.  
  497. AAron nAAs                              |\ \    Ptht...
  498.                                          'O.o    /
  499. Disclaimer:  Beware of my ego           =( )()=
  500. AAron@sun.soe.clarkson.edu                 U
  501.  
  502. P.S. Doesn't the most recent SI Ramdisk DA allow you to create ramdisks,
  503.      copy files to them on boot, and has print spooler stuff?  Plus there
  504.      are a few programs that you can put in the autofolder and read a
  505.      data file for info on what to copy where.
  506.  
  507. ------------------------------
  508.  
  509. Date: 16 Jul 91 14:18:37 GMT
  510. From: sae!malay@uunet.uu.net (Bob Malay)
  511. Subject: Reset-Proof Ramdisk
  512. To: Info-Atari16@naucse.cse.nau.edu
  513.  
  514. I'm looking for (either PD or commercial) a reset-proof ramdisk that will
  515. run on a 4Meg 1040Ste without bombs. I tried the eternal2 from a.a and I
  516. get two bombs. I then tried eternal from ST-Format and it gave two bombs.
  517.  
  518. I have a commercial piece of software that gives me bus errors when it is
  519. run on the 4MB STe - if I run it on a 1MB STe or a 1MB STf it works fine.
  520. I've run all kinds of memory-intensive stuff without problems so I'm
  521. assuming there's a bug in the commercial piece of software. Is there another
  522. way I can "fool" this program into believing I only have 1MB (short of
  523. yanking the SIMMS). I thought that if I would set up a 3MB reset-proof ramdisk
  524. and warm boot the buggy software that it might just work????
  525.  
  526. Bob Malay
  527.  
  528. ------------------------------
  529.  
  530. Date: 16 Jul 91 07:36:34 GMT
  531. From: mcsun!ukc!edcastle!hwcs!neil@uunet.uu.net (Neil Forsyth)
  532. Subject: Supra vs. ICD controllers
  533. To: Info-Atari16@naucse.cse.nau.edu
  534.  
  535. In article <1991Jul15.040751.4163@mailer.cc.fsu.edu> boyd@nu.cs.fsu.edu writes:
  536. > ... ICD software is far better than Supra's.  ...
  537.  
  538. I beleive they were both, at least initially, written by the same person,
  539. namely a Mr. W. Brown. Just another net curio. :-)
  540.  
  541. +----------------------------------------------------------------------------+
  542. ! DISCLAIMER:Unless otherwise stated, the above comments are entirely my own !
  543. !                                                                            !
  544. ! Neil Forsyth                      JANET:  neil@uk.ac.hw.cs                 !
  545. ! Dept. of Computer Science         ARPA:   neil@cs.hw.ac.uk                 !
  546. ! Heriot-Watt University            UUCP:   ..!ukc!cs.hw.ac.uk!neil          !
  547. ! Edinburgh, Scotland, UK           "That was never 5 minutes!"              !
  548. +----------------------------------------------------------------------------+
  549.  
  550. ------------------------------
  551.  
  552. Date: 16 Jul 91 04:38:38 GMT
  553. From:
  554.  noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!uakari.primate.wisc.edu!caen!spool.mu.e
  555.  du!agate!stanford.edu!leland.Stanford.EDU!jerzy@arizona.edu (J. Czaplicki)
  556. Subject: Wanted - info on Mega ST 8/16 MHz accelerators
  557. To: Info-Atari16@naucse.cse.nau.edu
  558.  
  559. Hello,
  560.  
  561. I'm considering buying an accelerator for my Mega ST2, but first I'd
  562. like to ask more experienced users, which of the accelerators currently
  563. available (from Gadgets by Small, Fast Technologies, ICD Inc.; are there
  564. any more?) is the best ? In particular I'd like to know the following:
  565.  
  566.         - how easy it is to install a given accelerator;
  567.         - what is the effective gain in speed (for computations,
  568.           graphics, etc);
  569.         - limitations (what programs won't work);
  570.         - is it really worth the price.
  571.  
  572. Besides, are T20 trustworthy ? What warranty comes with them ?
  573. I'd really appreciate comments on the above.
  574.  
  575. Thanks in advance,
  576. --
  577. Jerzy
  578.                               |  When you ask a question you seem to be   |
  579. | Email:                      |  silly for a while. But if you don't, you |
  580. | jerzy@leland.stanford.edu   |  remain silly for all your lifetime.      |
  581.  
  582. ------------------------------
  583.  
  584. Date: 16 Jul 91 14:21:02 GMT
  585. From:
  586.  noao!asuvax!ncar!elroy.jpl.nasa.gov!usc!cs.utexas.edu!utgpu!watserv1!watmath!lj
  587.  dickey@arizona.edu (L. J. Dickey)
  588. Subject: weather fax (wefax) satellite images on atari
  589. To: Info-Atari16@naucse.cse.nau.edu
  590.  
  591. In article <1991Jul12.223022.14357@ux1.cso.uiuc.edu>
  592.         banko@lisboa.ks.uiuc.edu (Brad Banko) writes:
  593. >several years ago, there was a circuit and program for 8-bit atari computers
  594. >(i apologize for posting this to .st, but i'll bet many of you have upgraded
  595. >to the st from 8-bit machines.) which could capture weather fax radio
  596. >signals and display the images on an 8-bit atari.
  597. >
  598. >are there any wefax enthusiasts out there who might be using such a system
  599. >on st machines or apple macintosh computers?
  600.  
  601. A couple of years ago Mike Gore ( magore@watserv1.UWaterloo.ca ) used
  602. his Atari ST to process weather satelite images.  He used two methods...
  603. One was direct processing during reception from his inexpensive short
  604. wave receiver and the other was to process tape recorded audio from the
  605. same.  He did have a simple AD circuit that transformed the sounds from
  606. the radio to something that could be processed by software on the ST.
  607.  
  608. He printed his images on his dot matrix printer.
  609.  
  610.  
  611.  
  612. --
  613. Prof L.J. Dickey, Faculty of Mathematics, U of Waterloo, Canada N2L 3G1
  614. internet:       ljdickey@watmath.UWaterloo.ca   BITNET/EARN:    ljdickey@watdcs
  615. obsolescent?:   ljdickey@watmath.waterloo.edu
  616. UUCP:           ljdickey@watmath.UUCP   ..!uunet!watmath!ljdickey
  617.  
  618. ------------------------------
  619.  
  620. End of Info-Atari16 Digest
  621. ******************************
  622.  
  623.